BachStudio Teradata MCP Server

Server Quality Checklist

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

Latest release: v0.1.6
Disambiguation4/5
Most tools have distinct purposes, but there is some overlap between base_tableUsage and dba_tableUsageImpact, which both measure table usage. Similarly, qlty_missingValues and qlty_rowsWithMissingValues could be confused, though they target different outputs. Overall, the tool set is reasonably disambiguated.
Naming Consistency3/5
Tool names use prefixes (base_, dba_, qlty_, sec_, sql_, rag_, plot_) but mixing camelCase (base_columnDescription) and underscores (sql_Analyze_Cluster_Stats) within the same server creates inconsistency. Naming after the prefix is also inconsistent: some are verb-noun (base_readQuery), others noun-noun (base_tableList).
Tool Count2/5
With 38 tools, the server is on the heavier side for a database interaction server. While the scope justifies many functions, several tools overlap (e.g., table usage metrics) and plotting tools feel slightly out of place, making the count feel excessive rather than lean.
Completeness3/5
The server covers broad areas (metadata, DBA, data quality, security, SQL optimization, RAG, plotting), but has notable gaps: no dedicated tools for DDL operations (create/alter/drop) beyond generic readQuery, and no individual RAG utilities (e.g., embedding search). The SQL optimization suite is thorough but dependent on pre-existing tables.
Average 3.2/5 across 38 of 38 tools scored. Lowest: 1.8/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 is passing
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description mentions returning a dict but no details on structure or behavior. No disclosure of side effects, authentication needs, or limitations. Relies on vague statement 'generates a pie chart plot'.
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?
Description is repetitive and contains irrelevant parameter descriptions. The two-sentence overview is clear but the subsequent parameter list is poorly structured and contains errors.
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?
No output schema, no annotations, and low schema coverage. The description fails to explain how parameters relate to the plot (e.g., column type, label format). Incomplete for a tool with three required parameters.
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 coverage is 0%. Parameter descriptions are present but misleading (refer to 'line plot' instead of pie chart). They add no real meaning beyond the schema, and the errors reduce clarity.
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 it generates a pie chart, but parameter descriptions mention 'line plot', indicating copy-paste errors. It does not clearly distinguish from sibling tools like plot_line_chart, plot_polar_chart, or plot_radar_chart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. No mention of prerequisites, context, or exclusions. Sibling tools exist but no differentiation.
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, the description must disclose behavioral traits. It mentions generating a plot but does not state read-only nature, required permissions, side effects, or impact on data.
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 includes a parameter list that redundantly echoes the schema with 'Required Argument' and types. It is not concise and contains unnecessary repetitions (e.g., 'line plot').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and a specialized plotting tool, the description is incomplete. It omits input format specifics, output structure, and fails to address potential errors or limitations.
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?
With 0% schema coverage, the description should add meaning beyond parameter names. It only repeats 'labels' and 'column' with minimal clarification ('Columns mentioned in labels...'), lacking details on expected format or constraints.
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 'generate a polar area plot', identifying the verb and resource, but it also mentions 'donut plot' and 'line plot', causing confusion. It does not effectively differentiate from sibling tools like plot_pie_chart or plot_radar_chart.
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. There is no discussion of prerequisites, context, or exclusion criteria.
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 provided, and the description only mentions it returns 'formatted response with query results + metadata'. No disclosure of behavior (e.g., does it scan entire table? costly? requires permissions?). Minimal transparency.
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 short and uses a clear 'Arguments/Returns' structure. However, the content is too sparse; conciseness sacrifices needed detail, making it merely adequate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and low schema coverage, the description should better explain return format and parameter semantics. 'Formatted response' is vague. Incomplete for the tool's complexity.
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 merely repeats parameter names without adding meaning. It does not explain the role of nullable 'database_name' (e.g., default to current database) or how 'table_name' is resolved.
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 'column summary statistics for a table'. It distinguishes from sibling tools like 'qlty_distinctCategories' and 'qlty_missingValues' by implying it returns aggregate statistics, though not explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus the many sibling tools (e.g., when to choose column summary vs distinct categories). No context on prerequisites or typical use cases.
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, the description must fully disclose behavioral traits. It only states 'Get', implying read-only, but lacks details on potential errors, rate limits, or data volume. The agent has minimal insight into the tool's behavior 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, making it efficient. However, the extreme brevity sacrifices necessary details, though it remains well-structured and front-loaded.
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 absence of an output schema and the simplicity of the tool, the description is insufficient. It does not explain what flow control metrics include or the expected response format, leaving the agent with significant uncertainty.
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 compensate. It mentions 'specified date range' but provides no format, allowed values, or semantics for start_date and end_date. The agent cannot determine how to correctly fill 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 action ('Get'), the resource ('Teradata flow control metrics'), and the scope ('for a specified date range'). This provides a specific purpose, but it does not differentiate from sibling tools like dba_resusageSummary that also retrieve metrics.
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, nor any exclusions or prerequisites. The description only implies date-range filtering, leaving the agent without context for appropriate invocation.
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?
The description offers no information beyond the basic action and resource. It does not disclose whether the operation is read-only, what the metrics represent, or any permissions required. With no annotations, the description carries the full burden and fails to add 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, making it concise, but it is overly minimal and does not prioritize key information. It is adequate in length but lacks structure and fails to front-load important details.
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 has no annotations, no output schema, and 2 required parameters, the description is insufficient. It does not convey what the metrics represent, how the date range is used, or what the response looks like, leaving significant gaps for an agent.
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 coverage is 0%, meaning the description does not explain the parameters' format or constraints beyond the schema's property names. The description mentions 'specified date range' but does not clarify date format (e.g., YYYY-MM-DD) or any valid ranges, so it adds minimal 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 identifies the action ('Get') and resource ('Teradata user delay metrics') and specifies the scope ('for a specified date range'). It is specific enough to distinguish from sibling tools that focus on other metrics like database space or feature usage, though it does not explicitly differentiate.
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, nor does it mention prerequisites, context, or when not to use it. This leaves the agent without decision-making support.
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, the description carries full burden for behavioral disclosure. It only states it generates a plot and returns a dict, but does not mention side effects, performance implications, required permissions, or what the dict contains. Incomplete for a chart-generation tool.
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 short, but includes a redundant parameter section that largely repeats schema info. The initial sentence is clear, but the overall structure could be more focused and less repetitive.
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 sibling plot tools and no output schema, the description should explain what kind of data suits radar charts and what the output represents. It does not, leaving the agent underinformed for tool selection.
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 gives minimal semantics: 'Columns mentioned in labels are used as labels and column is used to plot.' This is ambiguous (singular 'column' vs schema allowing array) and adds little beyond the schema's type info.
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 specifies 'generate a radar plot for labels and columns', which clearly indicates the tool's purpose. The tool name itself distinguishes it from sibling plot tools (line, pie, polar). However, the explanation of how labels and columns are used is somewhat confusing.
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 radar chart tool versus alternatives like line, pie, or polar charts. The description lacks context for selecting the appropriate visualization type.
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 provided, so description must fully disclose behavior. It mentions it returns formatted responses with metadata, but does not specify if the operation is read-only, if any side effects occur, or any required permissions. The description lacks depth on behavioral traits beyond the basic 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 moderately concise but includes a separate 'Arguments:' and 'Returns:' section that slightly bloats it. It could be streamlined to a single sentence. Some technical details (e.g., 'via SQLAlchemy') are included but may not be necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters and no output schema, the description covers the basic functionality. However, it lacks context on prerequisites (e.g., table existence, database permissions) and does not clarify the exact DDL format returned. Annotations could supplement, but they are absent.
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 description must compensate. However, it only repeats parameter names with minimal descriptions ('Database name' and 'table name'), adding no meaning beyond the schema. No examples, constraints, or formatting details are provided.
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 displays DDL definitions for a table, involving SQLAlchemy and bind parameters. It is specific about the resource (table DDL) and action (display), but does not explicitly differentiate from sibling tools like base_columnDescription or base_tablePreview, though the purpose is distinct enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. There is no mention of scenarios where it should be used or avoided, nor any reference to sibling tools like base_tableList or base_columnDescription that might cover similar needs.
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 must disclose behavior. It only states 'Get' but does not clarify if this is a read-only operation, what data is returned, or any authorization requirements. This lack of detail leaves ambiguity.
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 a single sentence with no wasted words. However, it could include more useful information without becoming verbose, such as listing what session information is included.
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 has one parameter and no output schema, the description should at least summarize the output content or behavior. It does not mention what session info is retrieved (e.g., session ID, user, start time), leaving the agent with incomplete understanding.
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 description should explain the parameter. It adds 'for user' which ties the parameter to the action, but does not elaborate on the expected format, constraints, or examples of user_name. The parameter's meaning is largely inferred from its name.
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 uses a specific verb 'Get' and resource 'Teradata session information'. It clearly indicates the tool's action and object, but does not differentiate from sibling tools like dba_userSqlList or dba_userDelay, which also involve user-specific data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not specify prerequisites, context, or exclusions. Users must infer usage from 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 must fully convey behavioral traits. It only indicates a read operation ('Get') but does not mention permissions, side effects, or what happens when no missing values exist. The return type is vaguely described as 'formatted response with query results + metadata', lacking specifics.
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 concise with two sentences plus a parameter list and return type. It is front-loaded with the purpose. However, the parameter descriptions are redundant with the schema, and the explanation could be slightly more structured without added length.
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 and no output schema, the description should fully specify behavior and return format. It does not clarify the format of returned column names (e.g., array, comma-separated) or handle edge cases like null database_name (allowed in schema). The return type 'formatted response' is too vague.
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?
With 0% schema description coverage, the description must add meaning. It repeats parameter names and labels (e.g., 'database_name - name of the database') which are already in the schema titles. No additional details like allowed values, defaults, or constraints are provided, adding minimal 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 retrieves column names with missing values. The verb 'Get' and resource 'column names having missing values' are specific. While it distinguishes from sibling tools like 'qlty_rowsWithMissingValues' by focusing on columns rather than rows, it does not explicitly differentiate from other qlty_* 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?
The description provides no guidance on when to use this tool versus alternatives like 'qlty_rowsWithMissingValues' or 'qlty_columnSummary'. There is no explicit recommendation, prerequisites, or exclusions stated. Usage is only implied by the tool's 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?
With no annotations, the description must disclose behavioral traits. It states the return type (formatted response with results and metadata) but omits details like whether the tool is read-only, permission requirements, or behavior with non-numeric columns, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, with one sentence for purpose and brief argument/return descriptions. It is front-loaded with the action (Get the column names...). However, the grammar is slightly awkward, and the structure could include a more formal 'Returns' section.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should thoroughly explain return values. 'Formatted response with query results + metadata' is vague; it does not specify the structure (e.g., list of strings) or whether it includes column types. Behavioral details like handling of empty results are missing.
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 add meaning beyond parameter names. It only restates the obvious ('database_name - name of the database'), providing no additional context like data types (beyond schema), allowed values, or relationships between 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: retrieving column names with negative values. It implies a specific focus on data quality, distinguishing it from sibling tools like qlty_missingValues or qlty_distinctCategories, though it does not explicitly differentiate them.
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. The description lacks context such as prerequisites (e.g., numeric columns only) or conditions that would make this tool preferable over others like qlty_univariateStatistics.
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 must disclose behavioral traits. It does not mention that the tool is a read-only query, any side effects, or performance implications. The description merely states the function without 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 concise, using a clear list for arguments and returns. It is front-loaded with the purpose. No redundant information.
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 output schema and low parameter description, the description is incomplete. It does not specify the type of statistics returned, error conditions, or data type constraints. Users are left guessing the tool's full capabilities.
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?
The description lists the three parameters but adds no semantics beyond the input schema. With 0% schema description coverage, the description fails to explain how parameters affect the result or what univariate statistics include (e.g., mean, median, count).
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 retrieves univariate statistics for a table, specifying the required arguments (database_name, table_name, column_name). However, it does not differentiate from sibling tools like qlty_columnSummary or qlty_standardDeviation, which may also provide column-level 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?
No guidance is given on when to use this tool versus alternatives such as qlty_columnSummary or qlty_standardDeviation. The description lacks any context about when to invoke this tool preferentially.
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 provided, so description carries burden. It mentions use of SQLAlchemy and return of rendered SQL metadata, but does not explicitly state read-only behavior or potential side effects. Some transparency but incomplete.
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?
Description mixes purpose with implementation details (SQLAlchemy, bind parameters) and return metadata. Could be more concise; the first sentence is clear, but subsequent text adds redundancy.
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 tool with one optional parameter and no output schema, description lacks detail on default behavior when database_name is null. Return format is vague ('formatted response with query results + metadata'). Leaves agent guessing.
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?
Only parameter is 'database_name' with schema coverage 0%. Description repeats 'Database name' without additional detail (e.g., format, required vs optional, behavior if omitted). Adds no value beyond 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 measures usage of tables and views by users, helping infer active objects. It mentions arguments and returns, but does not specify what exact metrics are provided (e.g., query counts, user counts). Distinguished from siblings like base_tableAffinity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings like dba_tableUsageImpact or base_tableAffinity. The description does not mention prerequisites, limitations, or 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?
With no annotations provided, the description carries the full burden for behavioral disclosure. It implies read-only but does not mention side effects, permissions, or data aggregation. Minimal 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?
Single sentence, no wasted words. Highly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 2 parameters, the description is minimal. It lacks detail on return values, metric interpretation, and behavioral constraints like limits or pagination.
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 coverage is 0%, so the description must compensate. It mentions 'specified date range' but provides no format, constraints, or examples for start_date and end_date.
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 for a specified date range'. It is specific but does not explicitly differentiate from sibling tools like dba_resusageSummary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as dba_resusageSummary or dba_tableUsageImpact. No exclusions or context provided.
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 provided. The description says 'generate a line plot' but does not specify side effects (read-only vs mutation), output format (e.g., image path, base64, HTML), or whether it modifies state. The return is only described as 'dict' with no further detail, which is insufficient for an agent to predict behavior.
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 short but includes a redundant PARAMETERS section that mostly repeats the input schema. The initial two sentences convey core purpose. Could be more structured (e.g., front-load purpose, then parameter details) and remove repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description should explain the return value in detail (e.g., keys of the dict, data format). It only says 'dict' with no elaboration. Additionally, the tool has 3 required parameters but the description doesn't clarify valid column types or format constraints, making it incomplete for robust agent 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 has no descriptions (0% coverage), so the description must compensate. It states table_name is the source table, labels are for x-axis (as string), columns for y-axis (as list of strings). However, the description of labels is vague ('Specifies the labels to be used') and the note about 'Columns mentioned in labels' is confusing. It adds basic meaning but not precise enough to fully disambiguate parameter roles.
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 states it generates a line plot using labels and columns, with x-axis from labels and y-axis from columns. This distinguishes it from sibling pie, polar, and radar chart tools. However, the phrase 'Columns mentioned in labels' is confusing, reducing clarity slightly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like plot_pie_chart. No prerequisites or context (e.g., table must exist, labels must be a column). The description leaves the agent to infer usage without any recommendations.
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?
With no annotations provided, the description must disclose behavioral traits. It mentions that bind parameters can be used and that fully rendered SQL is returned in metadata, which adds some transparency about side effects. However, it does not clarify if the tool is read-only, what permissions are needed, or any rate limits.
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 relatively short and front-loaded with the main purpose. The mention of bind parameters and SQL rendering is additional but not overly verbose. It could be more structured, but overall each sentence adds value.
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 has 2 required parameters, no output schema, and no annotations, the description is insufficient. It does not explain what 'detailed column information' includes (e.g., data types, nullability, constraints) nor the format of the response. An agent would have to infer behavior, leading to potential misuse.
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?
The description provides minimal parameter information: 'database_name' is described as 'Database name' and 'obj_name' as 'table or view name'. This barely adds meaning beyond the schema property names. With 0% schema description coverage, the description should compensate but fails to provide details about valid values, constraints, or defaults.
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 'shows' and the resource 'detailed column information about a database table'. It also adds context about bind parameters and SQL rendering, which is specific but somewhat broadens the scope. It distinguishes from siblings like base_tableDDL or base_tablePreview by focusing on columns specifically.
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 base_tableDDL or qlty_columnSummary. There is no mention of prerequisites, context, or exclusions, leaving the agent to infer usage from the tool name 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?
With no annotations, the description carries the full burden of behavioral disclosure. It only states that it returns a formatted response with query results and metadata, which is vague. It does not mention if the operation is read-only, performance implications, or data type requirements for the column.
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 concise, with a single sentence for purpose followed by a clean list of arguments and return type. No unnecessary words. However, the return type description could be more detailed.
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 statistical function and the presence of sibling tools, the description lacks details such as handling of non-numeric columns, null values, aggregation scope, and precise output format. No output schema is provided, so the description should explain more about the return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description adds basic meaning for each parameter (database name, table name, column name). While this clarifies the role of each parameter, the descriptions are minimal and could provide more context like expected data types or format.
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 computes standard deviation from a column in a table. The verb 'get' and resource 'standard deviation' are specific. However, it doesn't explicitly distinguish from sibling tools like qlty_univariateStatistics which may also compute standard deviation as part of a set of 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?
No usage guidelines are provided. The description does not specify when to use this tool versus alternatives such as qlty_univariateStatistics or other aggregation tools. No conditions or when-not-to-use are 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 full burden. It only states 'Get permissions' without revealing side effects, authorization needs, or potential impacts. The return type is vaguely described as 'formatted response with query results + 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 concise with a clear structure: purpose, arguments, returns. Every sentence serves a purpose, and it is front-loaded with the main action.
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 low complexity (1 parameter, no output schema) and lack of sibling differentiation, the description is incomplete. It does not clarify the scope of permissions (e.g., database-level, table-level) or the format of results, leaving significant gaps 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?
The description includes a brief parameter line 'user_name - user name to analyze', which adds some meaning beyond the schema's type and required status. However, the schema description coverage is 0% and the parameter description is minimal.
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 'Get permissions for a user', which is a specific verb and resource. However, it does not differentiate from sibling tools like sec_rolePermissions or sec_userRoles, leaving ambiguity about what type of permissions are retrieved.
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. There is no mention of prerequisites, context, or exclusion criteria, leaving the agent without decision support.
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 must disclose behavioral traits. It indicates a read operation but lacks details on side effects, authorization requirements, or error handling (e.g., missing role). The 'formatted response' mention is vague.
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 includes a structured Arguments/Returns section. No superfluous content. However, it could be more informative without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers the basic purpose and argument. It lacks completeness in terms of usage examples, return format details, or edge cases.
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?
With 0% schema description coverage, the description's argument note ('role name to analyze') adds minimal value beyond the schema's parameter name. No format, constraints, or examples are provided for role_name.
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 'Get permissions for a role' with a specific verb and resource. However, it does not explicitly distinguish from sibling tools like sec_userDbPermissions or sec_userRoles, though the role focus is implied.
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 use for retrieving role permissions but provides no guidance on when to use this versus alternatives. No context about prerequisites 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?
Minimal behavioral disclosure beyond the basic action. No mention of authentication, rate limits, or side effects. The return type is mentioned ('formatted response with query results + metadata'), but not enough context for an agent to anticipate 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?
Description is short and front-loaded with purpose. No irrelevant information, though the 'Arguments' block is redundant with the schema. Every part serves a purpose.
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?
Adequate for a simple list tool, but lacks details on default behavior when database_name is omitted. Does not mention whether results are scoped to the current connection or require additional setup.
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 coverage is 0%, so description must compensate. It adds a one-line explanation 'Database name' which is redundant with the schema title. No constraints, examples, or default behavior are described.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Lists all tables in a database' with a specific verb and resource. It distinguishes itself from sibling tools like base_databaseList (which lists databases) and table-specific tools like base_tablePreview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It simply describes the function without specifying exclusions or preferred 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, the description must fully disclose behavior. It implies a read operation but does not confirm read-only nature, access requirements, performance impact, or limitations. The word 'measure' suggests non-destructive action but is not explicit.
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 concise with two sentences and a parameter list, front-loading the purpose. Minimal waste, though the argument list could be integrated more cleanly.
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?
The tool lacks an output schema and has no annotations. The description does not specify return values or format, leaving a gap for agents to understand what the tool outputs. Also, parameter interaction is ambiguous.
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 adds basic meaning to parameters ('database name to analyze', 'user name to analyze'). However, it does not clarify behavior when both are null or the relationship between filtering (AND vs OR).
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 measures usage of tables and views by users, with a specific goal of identifying resource drivers. However, it does not explicitly differentiate from sibling tools like base_tableUsage or dba_tableSpace.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a use case (understanding resource usage) but lacks guidance on when to use this tool versus alternatives like base_tableUsage or dba_resusageSummary, and no exclusions or prerequisites.
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 provided. The description does not disclose whether the tool is read-only, what permissions are required, or how errors (e.g., missing user) are handled. The return format is vaguely described as 'formatted response with query results + metadata', which 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 concise with two sentences plus a structured arguments/returns section. However, the arguments/returns section partly duplicates the schema and could be integrated more efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description is barely adequate. It lacks details on data source, role semantics, and error behavior. It meets minimal requirements but leaves gaps.
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 bears the burden. It adds 'to analyze' to the parameter, providing slight context, but does not elaborate on expected input format or constraints. Baseline is low but description adds marginal value.
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 retrieves roles for a user. The verb 'Get' and resource 'roles assigned to a user' are specific. Among siblings like 'sec_rolePermissions' and 'sec_userDbPermissions', this tool's purpose is distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'sec_rolePermissions' or 'sec_userDbPermissions'. The description lacks context on prerequisites or use cases.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It discloses that the tool can bind parameters (if provided) and return fully rendered SQL with literals. It also specifies the return type as 'formatted response with query results + metadata'. However, it lacks details on side effects, permissions, performance implications, or how 'commonly used together' is determined (e.g., threshold). The description partially compensates for missing annotations but leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with the main purpose in the first sentence. It uses a bullet list for arguments and returns, which aids readability. However, there is slight redundancy: 'bind parameters if provided (prepared SQL), and return the fully rendered SQL (with literals) in metadata' could be tightened. Overall, it is efficient and front-loaded 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 the tool's complexity (inferring table relationships), the description covers the purpose, parameters, and return type but lacks completeness. It does not specify the output format beyond 'formatted response with query results + metadata', nor does it provide examples or clarify if data is real-time or cached. It also omits error handling, prerequisites (e.g., database must exist), and how the affinity is computed. With no output schema, more detail is needed for an agent to invoke it confidently.
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 adds meaning by explaining 'database_name' and 'object_name' (though the schema uses 'obj_name', not 'object_name'). However, there is a mismatch: the description says 'object_name' while the schema defines 'obj_name'. This inconsistency could confuse the agent. The description does not provide constraints, formats, or examples beyond basic identification. Given low coverage and the naming discrepancy, the added value is limited.
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: 'Get tables commonly used together by database users'. It specifies the verb 'Get' and the resource 'tables commonly used together', and explains how it helps infer relationships. This distinguishes it from sibling tools like base_tableUsage or base_tablePreview, which focus on different aspects (usage statistics, row preview).
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 does not provide explicit guidance on when to use this tool versus alternatives. It says 'this is helpful to infer relationships between tables', but does not mention when not to use it or compare it to sibling tools like base_tableDDL, base_tablePreview, or base_tableUsage. No exclusion criteria or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It states 'Get...summary metrics' but does not specify the actual metrics (e.g., CPU, IO), whether the operation is read-only, performance implications, or return format. The user is left uninformed about what data is returned or how aggregation works.
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 purpose in one sentence, followed by a bullet list of arguments with examples. While the list is somewhat lengthy, it is well-structured and each parameter is explained concisely. No redundant sentences, but the purpose could be slightly tighter.
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 8 parameters, no output schema, and no annotations, the description is incomplete. It does not describe the output format, the effect of combining multiple parameters, or how to interpret the summary metrics. Essential context for an agent to generate correct queries is missing.
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?
Despite 0% schema coverage, the description adds significant meaning: list of possible values for 'dimensions', example values for workloadType, workloadComplexity, and AppId (including wildcard patterns). This helps an agent understand which parameters to use and with what values, going beyond the schema titles.
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 retrieves 'Teradata system usage summary metrics' aggregated by 'weekday and hour for each workload type and query complexity bucket'. This distinguishes it from siblings like dba_featureUsage (features) and dba_flowControl (flow control) by specifying the exact resource and aggregation 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 explicit guidance on when to use this tool versus alternatives. The description lists parameters that can be used to filter, but does not advise on scenarios (e.g., 'use for historical analysis') or exclude use cases. Sibling tools like dba_sessionInfo or dba_userDelay are not mentioned, leaving the agent to infer usage context.
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 exist, so the description carries the full burden. It explains the output is a formatted response with query results and metadata, but lacks disclosure of side effects, permissions, rate limits, or data freshness.
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 concise, using a single sentence for the main behavior and a structured list for arguments/returns with no superfluous content.
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?
No output schema exists, and the description does not detail return format beyond 'formatted response'. Missing information on sorting, limits, pagination, or maximum days. Adequate for a simple list but leaves 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 coverage is 0%, meaning the description does not add meaning beyond parameter names and types. The description lists arguments with minimal explanations ('user_name - user name') and does not provide examples, constraints, or formatting details.
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 it gets a list of SQL run by a user or all SQL in the last number of days, with conditional logic based on whether a user name is provided. This is specific and distinguishes it from siblings like base_readQuery or dba_tableSqlList.
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 dba_tableSqlList or base_readQuery. The conditional logic provides some context but no when-not-to-use instructions.
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?
The description indicates a read-only operation (getting a list) and notes that the response is 'formatted response with query results + metadata.' However, it does not disclose potential side effects, authentication requirements, rate limits, or any destructive behavior. Since annotations are absent, the description carries the full burden and is minimally adequate.
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 very concise, using only three lines for purpose, arguments, and returns. Every sentence adds value, but the structure is a bit flat. Bullet points or clearer separation would improve readability. Still, it avoids verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with no output schema, the description is mostly complete. It covers the functionality and parameters, but lacks details about the output format (beyond 'formatted response') and does not differentiate from similar-purpose siblings. Given the context of many sibling tools, a bit more detail 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?
With 0% schema description coverage, the description adds meaning by explaining each parameter: 'table_name - table name' and 'no_days - number of days.' However, it does not specify the unit (days) beyond the name, nor does it clarify that no_days is optional with default 7 (schema shows default). The explanation is helpful but incomplete; e.g., it could state 'number of past days to include.'
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: 'Get a list of SQL run against a table in the last number of days.' It specifies a verb (get/list), resource (SQL queries for a table), and context (within recent days). This differentiates it from sibling tools like dba_userSqlList, which focuses on user-level SQL, and base_readQuery, which executes arbitrary 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?
No guidance is provided on when to use this tool over alternatives. With many sibling tools such as base_tableUsage, dba_featureUsage, or base_readQuery, the description should indicate scenarios where querying historical SQL by table is appropriate. The description simply states what it does without context for 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 must fully disclose behavioral traits. It only mentions 'formatted response with query results + metadata', lacking details on side effects, permissions, performance impact, or limitations.
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 concise: a single-sentence purpose followed by a clear list of arguments and return type. No superfluous information, well-structured and front-loaded.
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 simplicity, the description lacks details on result ordering, pagination, or sample size. It does not specify limitations or the exact nature of the 'formatted response'. Without an output schema, more context 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%, so the description adds meaning by naming and briefly explaining each parameter (database_name, table_name, column_name). While helpful, it could be more detailed about expected formats or constraints.
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 'Get the rows with missing values in a table', specifying a specific verb and resource. Among siblings like qlty_missingValues, it distinguishes itself by retrieving actual rows rather than summary statistics.
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 lists arguments but does not provide explicit guidance on when to use this tool versus alternatives. The purpose is implied but not explicitly stated with usage context 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, and the description only states the basic function and return type. It lacks details on permissions, scope, performance, or what 'databases' includes. With no annotations, the description carries the full burden and 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that front-load the core purpose. No wasted words.
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?
While the tool is simple (no params, no output schema), the description could elaborate on the scope of 'all databases' or how results are structured. Given many sibling tools, more context would help, but it's minimally 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?
Input schema has zero parameters, so schema coverage is 100% by default. The description adds no parameter info, but baseline for 0 params is 4, and the description does not detract.
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 'Lists all databases in the Teradata System,' which is a specific verb+resource. It distinguishes from sibling tools like base_tableList (tables) and base_columnDescription (columns).
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. Siblings include many list and database-related tools, but no context for selection.
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 must cover behavioral traits. It mentions SQLAlchemy, bind parameters, and SQL rendering, but lacks details on side effects (likely read-only), error behavior, or permissions required. The description is adequate but not thorough.
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 concise with two clear paragraphs: behavioral overview and argument/return listing. The first sentence effectively communicates the core purpose. Minor improvements could include front-loading key usage notes.
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?
With no output schema and limited parameter descriptions, the description covers basic functionality but lacks details on return format (beyond 'formatted response'), error handling, or edge cases. It is adequate for a simple preview tool but not comprehensive.
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 coverage is 0%, so the description must compensate. It repeats parameter names with minimal additional context (e.g., 'table or view name') but does not explain that database_name is optional (default null) or its role in specifying the database. No examples or constraints are provided.
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 returns a data sample and inferred structure from a database table or view, including rendered SQL. It distinguishes from siblings like base_tableDDL (DDL) and base_columnDescription (column info) by focusing on previewing sample data and structure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided. While the description implies it's for previewing table data, it does not differentiate from siblings like base_readQuery or advise on when to use this tool versus others.
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, and the description only states it retrieves space usage. It does not disclose behavioral traits such as whether it performs a read-only operation, requires specific permissions, or what the response format looks like.
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, concise sentence with no wasted words. It is front-loaded with the key action and resource.
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 simplicity (no parameters, no output schema, no annotations), the description is minimal but adequate. However, it lacks details on return format, units, or whether the data is real-time, which could be helpful for an agent. Score 3 reflects a minimum viable description.
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 zero parameters, and the input schema is empty. The description adds sufficient meaning by specifying what is being retrieved, which is the total system space. Per calibration, a baseline of 4 is appropriate for no-parameter tools.
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 'Get the Teradata total system database space usage' clearly specifies the verb 'Get' and the resource 'Teradata total system database space usage'. It differentiates from sibling tools like dba_databaseSpace and dba_tableSpace by emphasizing 'total system', indicating an aggregate scope.
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. No explicit recommendations, prerequisites, or exclusions are given.
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 bears full responsibility. It mentions SQL execution and bind parameters, suggesting some safety, but does not disclose whether the tool is read-only or allows modifications. The name 'readQuery' implies read-only, but the description does not confirm this or address potential risks.
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 concise at two sentences plus an Arguments section. It is front-loaded with the primary action. However, the Arguments section is somewhat redundant with the schema, slightly reducing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool complexity (executing SQL) and missing output schema require more detail. The description mentions returns include query results and metadata but lacks specifics on result format, pagination, limits, or safety constraints. With one parameter and no nested objects, completeness is adequate but not thorough.
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%, but the description adds meaningful context: it explains that 'sql' is SQL text with optional bind-parameter placeholders, clarifying the parameter's role beyond the type definition.
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 executes a SQL query via SQLAlchemy, with bind parameters, and returns the rendered SQL in metadata. It distinguishes itself from sibling tools like base_tablePreview and base_tableDDL by offering arbitrary SQL execution.
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. Sibling tools include specialized query tools, but no explicit when-to-use or when-not-to-use information is given.
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 does not disclose behavioral traits such as read-only nature, required permissions, or performance characteristics. The phrasing 'Get' suggests read-only but is not explicit.
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, well-structured sentence that directly states the tool's function. There is no wasted text, and it is appropriately front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description adequately conveys that it retrieves version info. However, it lacks details on the return format, which might be necessary for an agent without an output schema.
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?
There are zero parameters, so the input schema is trivial. According to the guidelines, 0 parameters yields a baseline of 4. The description adds no parameter information, which is acceptable here as none exist.
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 verb 'Get' and the resource 'Teradata database version information', making the purpose unambiguous. It is distinct from sibling tools like dba_databaseSpace which deal with space, not version.
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, use cases, or exclusions, leaving the agent to infer based solely on the name.
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?
With no annotations provided, the description carries the full burden. It implies a read-only operation ('Get') and describes the return type ('ResponseType: formatted response with query results + metadata'). This is adequate but lacks details on permissions, side effects, or limitations.
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 short and front-loaded with the purpose. It lists arguments and returns in a clear format without extraneous text. However, it could be slightly more structured (e.g., using bullet points or a table).
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 simple function (3 required parameters, no output schema, no annotations), the description covers the essentials. However, it could be more complete by clarifying what 'categories' means (e.g., distinct values for categorical columns) or the expected output format.
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 compensates by listing all three parameters with meaningful explanations: 'name of the database', 'table name to analyze', 'column name to analyze'. This adds substantial value beyond the schema's bare titles.
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: 'Get the destinct categories from column in a table.' It uses a specific verb ('Get') and resource ('distinct categories from column'), which distinguishes it from sibling tools like qlty_columnSummary or qlty_missingValues that analyze different aspects.
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 conditions, prerequisites, or exclusion criteria. The agent must infer usage from the tool name alone.
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?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool retrieves table space based on parameters, implying a read operation, but does not mention permissions, performance impact, or side effects. The description is accurate but minimal.
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 sentence that conveys the entire functionality without any extraneous words. It is efficient and front-loaded, making it easy for the agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description includes a return type line ('formatted response with query results + metadata'), providing basic context on output. Given the tool's simplicity and the absence of an output schema, this is adequate. However, for a database tool, additional context on what 'table space' means could be beneficial.
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 provides context for when each parameter is used ('if table name is provided' and 'if a database name is provided'), but does not specify format, constraints, or expected values. This partial compensation warrants a 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Get' and the resource 'table space'. It distinguishes between two modes: retrieving space for a specific table when table name is provided, or for all tables in a database when database name is provided. This differentiates it from sibling tools like base_tablePreview or dba_tableUsageImpact.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to provide table name versus database name, guiding the agent on parameter usage. However, it does not mention when not to use this tool, alternatives, or prerequisites, so it falls short of a 5.
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 that queries are categorized using configurable thresholds and mentions a query limit strategy, but does not describe the return format, edge cases (e.g., no queries found), or pagination. This is adequate but not thorough.
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 headers and bullet points, but it is quite long and includes extensive details about metrics and categories that might be excessive. It is not concise but is organized, earning a mid-range score.
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), the description provides a comprehensive overview: capabilities, selection strategies, performance categorization, workflow, and output contents. It references a config file for thresholds. Minor gaps exist (e.g., no output format details), but it is largely 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 schema has 0% description coverage, yet the description adds meaning by explaining that 'metric' is used for sorting (e.g., by CPU, I/O) and 'limit_per_cluster' is for limiting results, as seen in the 'QUERY LIMIT STRATEGY' section. It could be more explicitly tied to each parameter, but overall it adds significant value.
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 retrieves actual SQL queries from specific clusters for pattern analysis. It distinguishes from sibling tools like sql_Analyze_Cluster_Stats by positioning itself as the step after cluster-level analysis, providing a specific verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a 'TYPICAL OPTIMIZATION WORKFLOW' that starts with clusters from sql_Analyze_Cluster_Stats, then uses this tool, providing clear context for when to use it. However, it does not explicitly state when not to use it or mention alternatives beyond the workflow.
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?
No annotations are provided, so the description carries full burden. It comprehensively details the pipeline steps, performance metrics, and configuration, including the fact that it creates intermediate and final tables. It does not explicitly state side effects like table modification, but the workflow implies database writes.
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 sections and bullet points, and it is front-loaded with a bold summary. However, it is verbose; some details could be streamlined without losing value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the pipeline and the absence of output schema and annotations, the description covers workflow steps, metrics, configuration, use cases, and prerequisites. However, it does not explicitly describe the return value or output format, which is a notable gap for a pipeline tool.
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 mentions default values for max_queries and optimal_k from configuration, but does not provide a detailed explanation of each parameter's effect or allowed values. The description adds some context but is not comprehensive.
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 it executes the entire SQL query clustering pipeline for optimizing high CPU usage queries. It provides a step-by-step workflow and distinguishes itself from sibling tools like sql_Analyze_Cluster_Stats and sql_Retrieve_Cluster_Queries, which are post-pipeline steps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear use cases and optimization workflow are provided, along with prerequisites. However, there is no explicit contrast with alternatives like direct SQL queries or other tools. The description implies when to use it, but lacks explicit 'when not to use' guidance.
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 provided. Description indicates read operation ('get') and returns formatted response. Could be improved by specifying what 'space' includes (e.g., allocated vs used) or potential errors (e.g., database not found).
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?
Extremely concise: two lines plus argument. No filler, front-loaded with main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple query tool with 1 param and no output schema, description covers core functionality and return type. Lacks permission hints or error cases, but adequate for basic use.
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 has 0% coverage, so description adds meaning: parameter controls target scope (single DB vs all). Clarifies null behavior implicitly. Could add format expectations (e.g., case-sensitivity).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it gets database space for a specific database or all databases if name is omitted. This differentiates it from siblings like base_databaseList (list databases) and dba_tableSpace (table-level space).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to provide database_name and when to omit to get all spaces. No mention of when not to use, but the simple conditional is clear.
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?
No annotations provided, but the description fully discloses the tool's read-only analysis behavior, listing capabilities, metrics, and categorization logic. It does not mention side effects or required permissions but is transparent about its non-destructive nature.
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?
Well-structured with sections and bullet points, but somewhat verbose. The first paragraph is concise; subsequent sections add detailed guidance. Could be trimmed without losing value, but organization aids readability.
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?
Comprehensive coverage for a real-only analysis tool: explains what it does, how to use, output format, and optimization decision framework. No output schema, but the description adequately sets expectations for the returned data.
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%, but the description compensates by explaining both parameters: sort_by_metric with a full list of available metrics and their meanings, and limit_results as a refinement. This adds critical context 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: analyzing pre-computed cluster statistics for optimization opportunities, with specific verbs like 'analyze' and 'identify'. It differentiates from siblings like sql_Execute_Full_Pipeline by noting it avoids re-running the clustering pipeline.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit workflow steps (sort by metrics, limit results) and a decision framework for optimization. However, it lacks explicit exclusions or direct comparisons to alternatives, though the context implies when to use it.
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, the description fully covers behavioral traits: workflow steps, silent execution, answering rules, language restrictions, and how it handles configuration. It discloses that it strips /rag prefix, uses cosine similarity, and executes automatically without showing tool calls.
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 long but well-organized into sections (purpose, workflow, configuration, technical details, rules). It front-loads the core purpose and usage. While each section adds value, it could be slightly more concise without losing clarity.
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 and lack of output schema or annotations, the description thoroughly covers workflow, configuration, behavioral rules, error handling (e.g., partial context responses), and usage constraints. It provides all necessary context for correct 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 explains the 'question' parameter (user query with /rag prefix) but does not explicitly describe the optional 'k' parameter, which controls chunk retrieval count. Schema description coverage is 0%, so the description should compensate but only partially does.
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 executes a complete RAG workflow to answer user questions based on document context. It distinguishes from siblings which are primarily database utility tools, as this is an end-to-end RAG pipeline tool.
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?
Explicitly states when to use: when a user query is tagged with /rag. Also provides not-to-use guidance: 'RAG mode only triggers with explicit /rag prefix - do not enter RAG mode implicitly.' This clearly differentiates from other scenarios.
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

bachstudio-teradata-mcp-server MCP server

Copy to your README.md:

[![bachstudio-teradata-mcp-server MCP server](https://glama.ai/mcp/servers/BACH-AI-Tools/bachstudio-teradata-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/BACH-AI-Tools/bachstudio-teradata-mcp-server)

Score Badge

Copy to your README.md:

[![bachstudio-teradata-mcp-server MCP server](https://glama.ai/mcp/servers/BACH-AI-Tools/bachstudio-teradata-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/BACH-AI-Tools/bachstudio-teradata-mcp-server)

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/BACH-AI-Tools/bachstudio-teradata-mcp-server'

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