databricks-mcp
Server Quality Checklist
Latest release: v0.2.0
- Disambiguation4/5
Most tools have distinct purposes targeting specific Databricks resources (clusters, jobs, tables, etc.), but some overlap exists. For example, get_table_detail, get_table_schema, and get_table_history all focus on table metadata with potentially unclear boundaries for an agent. However, descriptions help differentiate them by specifying different aspects (detail vs. schema vs. history).
Naming Consistency5/5Tool names follow a highly consistent verb_noun pattern throughout, with clear and predictable conventions. All tools use either 'get_', 'list_', or 'search_' prefixes followed by the resource name (e.g., get_cluster_events, list_jobs, search_tables), making them easily readable and systematic.
Tool Count3/5With 25 tools, the count is borderline high for a single server, potentially overwhelming for an agent. While Databricks is a complex platform, this many tools might indicate fragmentation or redundancy, such as multiple table-related tools that could be consolidated. It feels heavy but not extreme.
Completeness4/5The tool set provides broad coverage for monitoring and querying Databricks resources, including clusters, jobs, tables, pipelines, and more. Minor gaps exist, such as lack of create/update/delete operations for many resources (e.g., no create_cluster or delete_job), but agents can work around this with the provided query tool for some operations. Core read and list functionalities are well-covered.
Average 2.8/5 across 25 of 25 tools scored. Lowest: 1.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but offers none. It doesn't indicate whether this is a read-only operation, whether it requires authentication, what the response format looks like, whether results are paginated, or any rate limits. For a listing tool with zero annotation coverage, this represents a complete failure to describe behavioral characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just two words, this represents under-specification rather than effective conciseness. The description doesn't front-load important information or provide any structure. Every word should earn its place, but here the words don't provide meaningful value beyond the tool name itself.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a listing tool with 2 parameters, no annotations, but with an output schema, the description is woefully incomplete. While the output schema may document return values, the description fails to explain what the tool does, when to use it, how parameters affect behavior, or any operational characteristics. For a tool in a rich ecosystem with many sibling alternatives, this description provides inadequate context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no information about parameters whatsoever. With 0% schema description coverage and two parameters (limit and expand_tasks), the description fails to explain what these parameters do, what values they accept, or how they affect the listing operation. The description doesn't compensate for the complete lack of parameter documentation in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List Jobs' is a tautology that merely restates the tool name without providing any meaningful elaboration. It doesn't specify what kind of jobs are being listed, what resource they belong to, or what scope is involved. While it's clear this is a listing operation, it fails to distinguish itself from sibling tools like 'list_job_runs' or 'get_job'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance on when to use this tool versus alternatives. With sibling tools like 'get_job' (for retrieving a specific job), 'list_job_runs' (for listing job runs), and 'list_pipelines' (for listing pipelines), there's no indication of how this tool differs or when it should be preferred. The description is completely silent on usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/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 but offers none. It doesn't indicate whether this is a read-only operation, what authentication is needed, potential rate limits, error conditions, or what format/details are returned. The description fails to provide any behavioral context 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just three words, which could be appropriate if it were more informative. However, this brevity results in under-specification rather than efficient communication. While front-loaded, it lacks the substance needed to be truly helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which reduces the need to describe return values), but with zero annotation coverage and 0% schema description coverage for its single parameter, the description is inadequate. For a job retrieval tool that likely returns structured data, the description should provide more context about what 'details' includes and parameter requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the single parameter 'job_id' has no documentation in the schema. The description adds no parameter information whatsoever - it doesn't explain what 'job_id' represents, where to find it, format requirements, or valid ranges. The description completely fails to compensate for the schema's lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get job details' is a tautology that essentially restates the tool name 'get_job' with minimal elaboration. While it indicates a retrieval action ('Get') and target resource ('job'), it lacks specificity about what 'details' entails and doesn't distinguish this tool from sibling tools like 'get_job_run' or 'list_jobs'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, when-not-to-use scenarios, or comparisons to sibling tools like 'get_job_run' (for run-specific details) or 'list_jobs' (for multiple jobs). The agent receives zero usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get run details' implies a read-only operation but doesn't specify permissions, rate limits, error conditions, or what the output contains. It fails to disclose any behavioral traits beyond the basic action, making it inadequate for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just three words, 'Get run details', which is front-loaded and wastes no space. However, this brevity comes at the cost of being under-specified, but as per the scoring rules, it earns a high score for conciseness alone.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 1 parameter with no schema description, no annotations, and an output schema exists (which might cover return values), the description is incomplete. It doesn't explain the tool's purpose in context, parameter meaning, or usage relative to siblings, making it insufficient for effective agent use despite the output schema potentially helping.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, meaning the parameter 'run_id' is undocumented. The description adds no information about what 'run_id' is, its format, or where to obtain it, failing to compensate for the schema's lack of documentation and leaving the parameter's meaning unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get run details' is a tautology that essentially restates the tool name 'get_job_run' without adding meaningful specificity. It mentions the verb 'get' and resource 'run details' but doesn't clarify what a 'run' is in this context or what specific details are retrieved, making it vague rather than informative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like 'get_job', 'list_job_runs', or 'get_run_task_metrics'. The description provides no context, prerequisites, or exclusions, leaving the agent with no information to make an informed choice among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get pipeline status' implies a read operation but lacks details on permissions, rate limits, error handling, or response format. This is inadequate for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just three words, front-loaded and free of unnecessary details. However, this brevity contributes to underspecification rather than effective communication.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description doesn't need to explain return values, but it lacks essential context for a tool with no annotations and undocumented parameters. It fails to clarify the tool's role among siblings or provide basic usage guidance, making it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about the 'pipeline_id' parameter. It doesn't explain what a pipeline ID is, its format, or where to obtain it, failing to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get pipeline status' restates the tool name 'get_pipeline' with minimal elaboration, making it tautological. While it specifies 'status' as the target, it doesn't distinguish this from sibling tools like 'list_pipelines' or 'list_pipeline_updates', leaving the scope unclear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With siblings like 'list_pipelines' and 'list_pipeline_updates', the description fails to indicate whether this is for detailed status of a single pipeline or how it differs from other pipeline-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/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 but provides none. 'List Clusters' doesn't indicate whether this is a read-only operation, whether it requires authentication, what the rate limits might be, whether results are paginated, or what format the output takes. The description is completely silent on all behavioral aspects that an agent would need to know.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is maximally concise at just two words. While this represents severe under-specification, from a pure conciseness perspective, there's zero wasted language. Every word (both of them) directly contributes to stating the tool's basic function. The structure is as simple as possible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a listing tool with one simple parameter and an output schema exists, the description could be minimal but still informative. However, 'List Clusters' provides insufficient context for an agent to understand what clusters are being listed, what system they belong to, or how this tool relates to the many sibling tools. The existence of an output schema helps, but the description doesn't even hint at what kind of data will be returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions no parameters at all, while the input schema has one parameter ('limit') with 0% schema description coverage. Since there's only one parameter and the description doesn't address it, this meets the baseline expectation. The schema provides the parameter structure, but the description adds no semantic context about what 'limit' means or how it affects the listing operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List Clusters' is a tautology that merely restates the tool name without adding any meaningful context. It doesn't specify what type of clusters, what system they belong to, or what specific action 'list' entails. While it matches the sibling tool naming pattern (e.g., 'list_catalogs', 'list_tables'), it fails to distinguish itself or provide purpose beyond the obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance on when to use this tool versus alternatives. With multiple sibling tools like 'get_cluster_events', 'get_cluster_metrics', and 'list_warehouses', there's no indication whether this is the primary way to retrieve cluster information or when other tools might be more appropriate. No context about prerequisites, timing, or relationships is mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'List job run history' implies a read-only operation but doesn't specify permissions needed, pagination behavior, rate limits, or what constitutes 'history' (time range, status filters). For a tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just three words. While this brevity comes at the cost of completeness, every word earns its place - 'List' specifies the action, 'job run' specifies the resource, and 'history' adds temporal context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values), the description's minimalism is somewhat acceptable. However, with 2 parameters (one required), 0% schema coverage, and no annotations, the description should do more to explain parameter meaning and behavioral context for a listing operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning neither parameter has documentation in the schema. The description provides no information about what 'job_id' refers to (what jobs, where they come from) or what 'limit' controls (number of runs, time range). It fails to compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List job run history' clearly states the verb ('List') and resource ('job run history'), making the basic purpose understandable. However, it doesn't distinguish this tool from potential siblings like 'get_job_run' or 'list_jobs' - it's vague about scope and differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'get_job_run' (singular) and 'list_jobs' (jobs rather than runs), there's clear potential for confusion, but the description offers no help in choosing between them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it's a read operation ('View'). It doesn't disclose behavioral traits such as permissions needed, rate limits, response format, or whether it's idempotent. For a tool with no annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise—a single phrase with no wasted words—and front-loads the core purpose. However, it could be more structured by separating purpose from usage notes, but it efficiently communicates the essential action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values), the description's minimalism is somewhat acceptable. However, with no annotations, 3 undocumented parameters, and multiple sibling tools, it lacks completeness in guiding usage and parameter understanding, making it only minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain what 'catalog', 'schema', or 'table' mean in this context, their expected formats, or examples. With 3 required parameters and no schema descriptions, this leaves critical gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('View Delta table details') and specifies the resource type ('Delta table'), which distinguishes it from siblings like get_table_schema or get_table_history. However, it doesn't explicitly differentiate from all table-related siblings, missing an opportunity to clarify its unique 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/5Does 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 get_table_schema or get_table_history. It mentions the SQL command 'DESCRIBE DETAIL' but doesn't explain what details it provides compared to other table inspection tools, leaving the agent 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 carries the full burden of behavioral disclosure. It mentions 'DESCRIBE EXTENDED', hinting at a detailed output, but doesn't clarify if this is a read-only operation, what permissions are required, whether it's cached, or any rate limits. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, consisting of a single, efficient phrase: 'Get table structure (DESCRIBE EXTENDED)'. Every word earns its place by conveying the core purpose and hinting at the output detail, with zero waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 required parameters) and the presence of an output schema, the description is minimally adequate. The output schema likely covers return values, reducing the need for description detail. However, with no annotations and 0% schema coverage for inputs, the description should do more to explain parameter semantics and usage context to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning beyond what the input schema provides. With 0% schema description coverage, the three required parameters (catalog_name, schema_name, table_name) are undocumented in both the schema and description. The description doesn't explain what these parameters represent, their formats, or examples, failing to compensate for the schema's lack of documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Get table structure (DESCRIBE EXTENDED)', which includes a specific verb ('Get') and resource ('table structure'). It distinguishes itself from siblings like 'get_table_detail' or 'get_table_history' by focusing on schema/structure rather than metadata or lineage. However, it doesn't explicitly differentiate from 'search_tables' or 'list_tables', which could also relate to table information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose 'get_table_schema' over 'get_table_detail', 'get_table_history', or 'search_tables', nor does it specify any prerequisites or exclusions. The agent must infer usage from the tool name and context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('list') but doesn't clarify if this is a read-only operation, what permissions might be required, whether results are paginated, or any rate limits. For a tool with no annotations, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place by conveying essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description doesn't need to explain return values. However, with no annotations, 0% schema description coverage, and multiple sibling tools, the description is minimal. It covers the basic purpose but lacks details on usage, parameters, or behavior, making it adequate but incomplete for effective tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so parameters 'pipeline_id' and 'limit' are undocumented in the schema. The description doesn't add any semantic details about these parameters, such as what 'pipeline_id' refers to or how 'limit' affects the output. However, with only 2 parameters and a default for 'limit', the baseline is 3 as the schema provides basic structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List pipeline update history' clearly states the verb ('list') and resource ('pipeline update history'), making the purpose understandable. However, it doesn't distinguish this tool from sibling tools like 'list_pipelines' or 'get_pipeline', leaving ambiguity about what specifically differentiates pipeline updates from pipelines themselves.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'list_pipelines' and 'get_pipeline' available, there's no indication of whether this tool is for historical changes, recent updates, or a specific subset of pipeline data, leaving the agent to guess based on the 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?
No annotations are provided, so the description carries full burden. It discloses the basic action but lacks behavioral traits: no info on permissions required, rate limits, output format (though output schema exists), pagination, or error handling. This is inadequate for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero waste—it directly states the tool's function without fluff. It's appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 1 parameter, no annotations, and an output schema, the description is minimally complete. It covers the basic purpose but lacks context on usage, behavior, and parameter details. The output schema mitigates the need to explain return values, but overall it's adequate with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 minimal semantics by specifying that 'catalog_name' is required and used to list schemas, but doesn't explain format, constraints, or examples. With 1 parameter and low coverage, this is a baseline score as it provides some context but not enough detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('List') and resource ('schemas'), but it's vague about scope—it doesn't specify if this lists all schemas, only active ones, or includes metadata. It distinguishes from siblings like 'list_tables' or 'get_table_schema' by focusing on schemas, but lacks specificity about what 'list' entails (e.g., pagination, filtering).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 is provided. It doesn't mention prerequisites (e.g., needing catalog access), exclusions, or compare to siblings like 'list_catalogs' or 'get_table_schema'. The agent must infer usage from the 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the basic action without mentioning permissions needed, whether it's read-only, pagination behavior, rate limits, or what the output looks like. This is inadequate for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—just four words—and front-loaded with the core action. There's no wasted language, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which reduces the need to describe return values) but no annotations and minimal parameter coverage, the description is incomplete. It covers the basic purpose but lacks behavioral and usage context needed for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description doesn't mention any parameters, but the input schema has one parameter 'path' with 0% description coverage. Since there's only one parameter and the description doesn't add any semantic context, it meets the baseline of 3 for minimal parameter documentation, but doesn't compensate for the lack of schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List Workspace directory contents' clearly states the action (list) and resource (workspace directory contents), but it's somewhat vague about what 'workspace directory' specifically refers to in the Databricks context. It doesn't differentiate from sibling tools like 'list_volumes' or 'list_tables', which might also list workspace-related items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools like 'list_catalogs', 'list_schemas', and 'list_tables' that might list related resources, there's no indication of scope, hierarchy, or prerequisites for using this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the action ('View') but doesn't specify whether this is read-only, if it requires specific permissions, what the output format is, or any rate limits. The parenthetical '(DESCRIBE HISTORY)' adds some context but 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single, front-loaded sentence and a brief parenthetical. There is no wasted text, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is an output schema (which handles return values), the description's minimalism is somewhat acceptable. However, for a tool with 4 parameters (3 required) and no annotations, it lacks details on behavior, usage, and parameter meanings, making it incomplete for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It doesn't explain what 'catalog', 'schema', 'table', or 'limit' mean, their expected formats, or how they relate to Delta tables. The description adds no parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('View Delta table change history') and specifies the resource type ('Delta table'), which distinguishes it from siblings like get_table_detail or get_table_schema. However, it doesn't explicitly differentiate from get_table_lineage or other history-related tools, keeping it at a 4 rather than a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 get_table_detail or get_table_lineage, nor does it mention prerequisites or context for invoking it. It simply restates the purpose without usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states it's a list operation but doesn't describe return format, pagination, permissions needed, rate limits, or error conditions. This leaves significant gaps for a tool that interacts with database schemas.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for a simple list operation and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values) and relatively simple functionality, the description covers the basic purpose adequately. However, with no annotations and poor parameter documentation, it leaves important behavioral and usage context unspecified for a database interaction tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for both required parameters, the description only mentions 'specified schema' which partially covers 'schema_name' but completely ignores 'catalog_name'. It doesn't explain what these parameters represent, their format, or valid values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('tables in the specified schema'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'list_catalogs' or 'list_schemas', but the specificity of 'tables' provides some implicit distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 'search_tables' or 'get_table_detail'. It mentions the schema parameter but doesn't explain prerequisites, context, or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'List' implies a read-only operation, but the description doesn't disclose any behavioral traits - no information about authentication requirements, rate limits, pagination, or what happens when invalid catalog/schema parameters are provided. It's minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single phrase with zero wasted words. It's front-loaded with the essential information (list Unity Catalog Volumes) and doesn't include any unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (which should document return values), the description's minimalism is somewhat acceptable. However, for a tool with 2 required parameters and 0% schema description coverage, the description should provide at least basic parameter context. It's borderline adequate but leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description adds no information about the two required parameters (catalog and schema) - it doesn't explain what they represent, their format, or their relationship. The description fails to compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('Unity Catalog Volumes'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'list_catalogs', 'list_schemas', or 'list_tables', which all follow the same 'list_[resource]' pattern for Unity Catalog entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. With multiple list tools available (list_catalogs, list_schemas, list_tables), the description doesn't explain that this specifically lists volumes within a catalog and schema, nor does it mention prerequisites or relationships to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool searches tables by name using information_schema, which implies a read-only operation, but doesn't clarify aspects like permissions required, rate limits, pagination, or what the search returns (e.g., partial matches, case sensitivity). This leaves significant gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core purpose and includes a useful technical detail ('using information_schema'). Every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which should document return values), the description doesn't need to explain outputs. However, with 2 parameters, 0% schema coverage, and no annotations, the description is incomplete—it lacks details on parameter usage, behavioral traits, and differentiation from siblings. It's minimally adequate but has clear gaps for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions searching 'by name', which relates to the 'keyword' parameter, but doesn't explain what 'keyword' entails (e.g., substring matching) or the purpose of the 'catalog' parameter. The description adds minimal value beyond the schema, failing to fully address the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search tables by name (using information_schema)'. It specifies the verb ('Search'), resource ('tables'), and scope ('by name'), though it doesn't explicitly differentiate from siblings like 'list_tables' or 'get_table_detail'. The mention of 'information_schema' adds technical context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention siblings like 'list_tables' (which might list all tables) or 'get_table_detail' (which might retrieve specific table metadata), nor does it specify prerequisites or exclusions. Usage is implied but not articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it's a list operation, implying read-only, but doesn't cover aspects like pagination, rate limits, authentication needs, or what 'all' means (e.g., all accessible catalogs). This leaves significant gaps for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence 'List all catalogs', which is front-loaded and wastes no words. It efficiently conveys the core purpose without unnecessary elaboration, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, 100% schema coverage, and an output schema exists, the description is minimally adequate. However, with no annotations and multiple sibling list tools, it lacks context about how catalogs fit into the hierarchy or what the output entails, leaving room for confusion in a rich server environment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add param info, which is appropriate here, but it also doesn't imply any hidden parameters or constraints, keeping it straightforward for a no-param tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all catalogs' clearly states the action (list) and resource (catalogs), but it's vague about scope or format. It doesn't distinguish from siblings like 'list_schemas' or 'list_tables' beyond the resource name, leaving ambiguity about what a 'catalog' entails in this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With siblings like 'list_schemas' and 'list_tables', the description doesn't explain if catalogs are a higher-level container or how they relate, nor does it mention prerequisites or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool returns event history with time in local timezone, which adds some context, but lacks details on permissions, rate limits, pagination, or error handling. For a read operation with no annotations, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement followed by 'Args:' and 'Returns:' sections. It's front-loaded and efficient, though the 'Args:' section could be slightly more detailed given the low schema coverage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters with 0% schema coverage and no annotations, but with an output schema (implied by 'Returns: Event list'), the description is moderately complete. It covers parameters and return type, but lacks behavioral context like error cases or performance considerations, making it adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 explicitly lists both parameters ('cluster_id' and 'limit') with brief explanations, adding meaning beyond the bare schema. However, it doesn't specify format for 'cluster_id' or constraints for 'limit' beyond 'Max number of records', leaving some gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get cluster event history' with specific event types listed (start, terminate, resize, errors, etc.). It uses a specific verb ('Get') and resource ('cluster event history'), but doesn't explicitly differentiate from sibling tools like 'list_clusters' or 'get_cluster_metrics' beyond the event focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context for usage, or compare it to sibling tools like 'list_clusters' or 'get_cluster_metrics', leaving the agent to infer usage based on the 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 provided, the description carries full burden but offers minimal behavioral insight. It states 'View object permissions' which implies a read-only operation, but doesn't disclose authentication needs, rate limits, error conditions, or what the output contains beyond permissions. This is inadequate for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose statement followed by parameter explanations. Every sentence adds value, and it's appropriately brief for a tool with only two parameters. Minor improvement could be made by integrating the parameter details more seamlessly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values) and only two parameters, the description covers the basics but has gaps. It explains parameters well but lacks behavioral context and usage guidelines. For a permissions-viewing tool with no annotations, more detail about what 'permissions' includes would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context beyond the input schema. While schema description coverage is 0%, the description explains that securable_type includes values like 'TABLE, SCHEMA, CATALOG, VOLUME, etc.' and that full_name uses 'catalog.schema.table format'. This provides essential semantic understanding that the raw schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'View object permissions' with the specific action 'SHOW GRANTS'. It identifies the resource as 'object permissions' but doesn't explicitly differentiate from sibling tools like get_table_schema or get_table_detail, which focus on different aspects of database objects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, appropriate contexts, or compare it to sibling tools like get_table_detail or list_tables, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions returning 'Task setup/execute/cleanup times' but lacks behavioral details such as authentication requirements, rate limits, error conditions, or whether this is a read-only operation. The description adds minimal context beyond the basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with the core purpose stated first. The Args and Returns sections are structured but slightly verbose; every sentence earns its place by clarifying inputs and outputs, though it could be more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description doesn't need to detail return values extensively. It covers the purpose and parameter semantics adequately for a single-parameter query tool. However, with no annotations and minimal behavioral transparency, it could improve by adding context like authentication or error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 the single parameter 'run_id' as 'Job Run ID'. This adds meaning beyond the schema's type definition. However, it doesn't provide format details (e.g., where to obtain run_id) or constraints, keeping it at a baseline level.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('job run task execution time details'), making the purpose understandable. It distinguishes from siblings like 'get_job_run' by specifying task-level timing metrics rather than general run information. However, it doesn't explicitly contrast with all similar siblings like 'get_cluster_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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing a valid run_id from another operation), exclusions, or comparisons to sibling tools like 'get_job_run' or 'list_job_runs'. Usage is implied but not explicitly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states 'List' which implies a read operation, but doesn't mention pagination behavior, rate limits, authentication requirements, or what 'Delta Live Tables Pipelines' specifically entails. The description is too minimal to provide adequate 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just four words, with zero wasted language. It's front-loaded with the essential action and resource, making it efficient for quick scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a simple list operation with only one optional parameter and an output schema exists, the description is minimally adequate. However, with no annotations and multiple sibling tools that could cause confusion, the description should provide more context about what distinguishes this tool from alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions no parameters at all, while the schema has one parameter (limit) with 0% description coverage. Since there's only one parameter and the description doesn't add any semantic information about it, this meets the baseline for minimal parameter documentation but doesn't compensate for the schema coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('Delta Live Tables Pipelines'), making the purpose immediately understandable. It doesn't distinguish from siblings like 'list_pipeline_updates' or 'get_pipeline', but it's specific enough to identify the target resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 'list_pipeline_updates' or 'get_pipeline'. There's no mention of context, prerequisites, or exclusions that would help an agent choose between these related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes a read operation ('List') but lacks details on permissions, rate limits, pagination, or what the output contains. The mention of 'limit' hints at result truncation, but it doesn't explain default ordering or if results are sorted by time. This is inadequate for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a brief purpose statement followed by a parameter list. Each parameter explanation is concise and to the point. There's no redundant information, and the formatting makes it easy to scan. However, the lack of usage context slightly reduces efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (5 parameters, no annotations, but has an output schema), the description is partially complete. It covers parameter semantics well but lacks behavioral context and usage guidelines. The presence of an output schema means the description doesn't need to explain return values, but it should still address when and how to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides clear semantics for all 5 parameters, explaining their optional nature, filtering purposes, and format details (e.g., 'local format "YYYY-MM-DD HH:MM:SS"' for time parameters). This adds significant value beyond the bare schema, though it doesn't cover edge cases like timezone handling.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List SQL query history' specifies the verb ('List') and resource ('SQL query history'). It distinguishes from some siblings like 'list_tables' or 'list_warehouses' by focusing on query history, though it doesn't explicitly differentiate from all potential alternatives like 'databricks_query' which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, context for usage, or comparisons with sibling tools like 'databricks_query' or 'search_tables'. The agent must infer usage based solely on the tool name and parameters.
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 for behavioral disclosure. 'List SQL Warehouses' implies a read-only operation, but it doesn't specify any behavioral traits like pagination, rate limits, authentication requirements, or what the output contains. For a tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient phrase ('List SQL Warehouses') that directly states the purpose with zero wasted words. It's appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, output schema exists), the description is minimally adequate. However, with no annotations and many sibling tools, it lacks context about when to use it and behavioral details. The output schema handles return values, but the description doesn't provide enough guidance for an agent to use it effectively in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% description coverage, so no parameter documentation is needed. The description doesn't add parameter information, which is appropriate here. A baseline of 4 is given for tools with zero parameters, as there's nothing to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('SQL Warehouses'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its many sibling list tools (e.g., list_catalogs, list_clusters, list_tables), which all follow the same 'List [resource]' pattern, so it misses full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling list tools available, there's no indication of what distinguishes SQL Warehouses from other resources or when this specific listing is appropriate. No exclusions or prerequisites are mentioned.
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 discloses the data source and that it returns time series and summary statistics, which adds useful behavioral context. However, it lacks details on permissions, rate limits, error handling, or whether it's read-only/destructive, which are important for a metrics retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, data source, args, returns) and uses bullet points for readability. It's appropriately sized without fluff, though the data source detail might be slightly verbose for a pure purpose statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, no annotations, but with an output schema), the description is fairly complete. It covers purpose, parameters, and return values, and the output schema reduces the need to detail return formats. However, it could improve by addressing usage guidelines and more behavioral aspects like error cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 effectively explains all four parameters: 'cluster_id' is identified, 'start_time' and 'end_time' specify ISO format with defaults, and 'limit' defines its purpose and default. This adds significant meaning beyond the bare schema, though it could elaborate on constraints like valid time ranges.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resources ('cluster CPU/Memory/Network/Disk metrics'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'get_cluster_events' or 'get_run_task_metrics', which might also involve cluster-related data retrieval, leaving some ambiguity about when this specific tool is preferred.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions the data source ('system.compute.node_timeline'), but doesn't specify use cases, prerequisites, or exclusions compared to siblings like 'get_cluster_events' or 'get_run_task_metrics', leaving the agent 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It mentions that including notebooks/jobs is 'slower', which is useful behavioral context about performance trade-offs. However, it doesn't disclose other important traits like authentication requirements, rate limits, error conditions, or whether this is a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (Args, Returns) and front-loaded purpose statement. The description is appropriately sized with no wasted sentences, though the performance note about 'slower' could be more precisely worded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (5 parameters, lineage analysis), no annotations, but with an output schema present, the description provides good coverage. It explains parameters well and outlines the return structure. The main gap is lack of usage context relative to sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It provides clear explanations for all 5 parameters in the Args section, including the purpose of each parameter and default values. The only minor gap is not explaining format expectations for catalog/schema/table names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get table lineage') and resources involved ('upstream/downstream tables and related notebooks/jobs'). It distinguishes this tool from siblings like get_table_detail or get_table_schema by focusing on lineage relationships rather than metadata or structure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. While siblings like get_table_detail or search_tables exist, the description doesn't explain when lineage information is needed versus other table metadata or how this tool complements them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively communicates key behavioral traits: the tool executes SQL queries, supports specific operation types, blocks destructive operations, and returns query results as list of dicts. It doesn't mention authentication requirements, rate limits, or error handling, but provides solid core behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose statement upfront, followed by specific operational boundaries, then parameter explanations, and finally return format. Every sentence earns its place with no redundant information, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (SQL execution with operation restrictions), no annotations, and the presence of an output schema (which handles return value documentation), the description provides strong contextual completeness. It covers purpose, usage boundaries, parameter roles, and behavioral constraints. The main gap is lack of authentication/error handling details, but overall it's quite complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for the 2 parameters, the description compensates well by explaining that 'sql_query' is the preferred parameter for SQL query statements while 'sql' serves as a fallback for backward compatibility. This adds meaningful context beyond the bare schema, though it doesn't provide format examples or validation rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Execute Databricks SQL query') and resource ('Databricks'), and explicitly distinguishes this tool from its siblings by listing supported operations (SELECT, SHOW, DESCRIBE, CREATE, ALTER) and blocked operations (INSERT, UPDATE, DELETE, DROP). This provides precise differentiation from read-only sibling tools like get_table_schema or list_tables.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool (for executing SQL queries with specific allowed operations) and when not to use it (for destructive operations like INSERT, UPDATE, DELETE, DROP which are blocked). This clearly establishes the tool's scope and limitations relative to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/ChrisChoTW/databricks-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server