Databricks MCP Server

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Every tool has a clearly distinct purpose targeting specific Databricks resources and actions. There is no ambiguity: create_* tools create resources, list_* tools list resources, execute_sql vs execute_sql_nonblocking handle different execution modes, and upload_file_to_dbfs vs upload_file_to_volume target different storage systems. The descriptions reinforce these distinctions.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with snake_case throughout. Verbs like create, list, get, execute, run, start, terminate, export, and upload are used predictably with appropriate nouns (cluster, job, notebook, sql, files, etc.). There are no deviations in naming conventions.
Tool Count4/5
With 19 tools, the count is slightly high but reasonable for a comprehensive Databricks interface covering clusters, jobs, notebooks, SQL execution, and file management. It includes core operations for each domain without being excessive, though some tools like list_job_runs and list_jobs could potentially be consolidated to reduce count.
Completeness5/5
The tool surface provides complete CRUD/lifecycle coverage for Databricks domains: clusters (create/get/list/start/terminate), jobs (create/list/run with detailed run tracking), notebooks (create/list/export), SQL execution (blocking/non-blocking with status check), and file management (list/upload for both DBFS and Unity Catalog volumes). There are no obvious gaps that would cause agent failures.
Average 3.2/5 across 19 of 19 tools scored. Lowest: 1.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Run a Databricks job' but fails to disclose critical traits: whether this is a read or write operation (likely a write that triggers execution), what permissions or authentication are needed, potential side effects (e.g., resource consumption, job execution), rate limits, or what happens on success/failure. For a tool that likely performs a significant action, this lack of detail is inadequate.
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, efficient sentence with zero waste—it's appropriately sized and front-loaded. However, it's overly concise to the point of under-specification, lacking necessary details. While it earns points for brevity, it sacrifices clarity, so it's not a perfect 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a likely write operation to run jobs), no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It doesn't explain what the tool does beyond the name, provide usage context, detail parameters, or describe expected outcomes. For a tool in a Databricks environment with many siblings, this is severely inadequate.
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 schema description coverage is 0%, meaning parameters are undocumented in the schema. The description adds no meaning beyond the schema—it doesn't explain what 'job_id' refers to (e.g., an existing job identifier) or what 'notebook_params' are (e.g., key-value pairs for notebook execution). With 2 parameters and no schema descriptions, the description fails to compensate, leaving semantics unclear.
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 'Run a Databricks job' is a tautology that essentially restates the tool name. It specifies the verb ('Run') and resource ('Databricks job'), but doesn't distinguish this from sibling tools like 'create_job' or 'list_job_runs'—it doesn't clarify what 'running' entails versus creating or listing. While it identifies the basic action, it lacks specificity about what the tool actually does 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing job), exclusions (e.g., not for creating jobs), or context for choosing it over siblings like 'execute_sql' or 'list_job_runs'. There's no indication of appropriate scenarios, making it misleading if an agent assumes it can create or manage jobs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool creates a cluster but doesn't describe what happens after creation (e.g., whether it starts automatically, returns a cluster ID, or has side effects like billing implications). It lacks details on permissions required, rate limits, or error conditions, leaving significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It's front-loaded with the core action and resource, making it easy to scan. Every word earns its place by directly stating the tool's purpose without redundancy or fluff.
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 mutation tool with 4 parameters, 0% schema description coverage, no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns, how to use the parameters, or behavioral aspects like idempotency or error handling. The agent lacks sufficient context to use this tool effectively beyond basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate by explaining parameters, but it provides no parameter information. The description doesn't mention any of the four parameters (cluster_name, spark_version, node_type_id, num_workers) or their purposes, leaving them entirely undocumented. This fails to add value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('new Databricks cluster'), making the purpose immediately understandable. It distinguishes this from sibling tools like 'get_cluster', 'list_clusters', 'start_cluster', and 'terminate_cluster' by specifying creation rather than retrieval or management. However, it doesn't explicitly differentiate from other creation tools like 'create_job' or 'create_notebook' beyond the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing proper permissions or available resources), when not to use it (e.g., if a cluster already exists), or how it relates to sibling tools like 'start_cluster' or 'terminate_cluster'. 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.
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 but offers minimal information. It states the tool creates a notebook but doesn't cover critical aspects like authentication requirements, rate limits, error conditions (e.g., invalid paths), or what happens on success (e.g., returns a notebook ID). For a mutation tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse. Every part of the sentence ('Create a new notebook in the Databricks workspace') directly contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation operation with 4 parameters), lack of annotations, 0% schema description coverage, and no output schema, the description is incomplete. It doesn't address behavioral traits, parameter meanings, return values, or usage context, leaving significant gaps for an AI agent to invoke it correctly.
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 input schema has 0% description coverage, so parameters are undocumented in the schema. The description adds no parameter semantics—it doesn't explain what 'path', 'content', 'language', or 'overwrite' mean, their formats, or constraints (e.g., path syntax, language options). This fails to compensate for the schema gap, leaving parameters largely ambiguous.
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 ('Create a new notebook') and resource ('in the Databricks workspace'), making the purpose immediately understandable. However, it doesn't differentiate this tool from potential siblings like 'upload_file_to_dbfs' or 'export_notebook' that might also create notebook-like resources, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., workspace access), contrast with similar tools (e.g., 'upload_file_to_dbfs' for files vs. notebooks), or specify use cases (e.g., for interactive coding vs. batch jobs). This leaves the agent with minimal context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Export' implies a read operation that generates output, but the description doesn't specify what happens (e.g., file download, storage location, format defaults, permissions needed, or error conditions). It lacks critical details for safe and effective use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to scan. Every word contributes directly to the purpose.
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 (export operation with 2 parameters), no annotations, 0% schema coverage, and no output schema, the description is incomplete. It doesn't explain parameters, behavioral traits, or output format, leaving significant gaps for the agent to operate effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter details. The description mentions no parameters at all, failing to explain 'path' (e.g., notebook path in workspace) or 'format' (e.g., export formats like JUPYTER). It doesn't 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Export') and resource ('a notebook from the workspace'), making the purpose understandable. However, it doesn't distinguish this tool from potential sibling export operations (none are listed, but it could be confused with general file export tools). The description is specific but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., notebook must exist), exclusions, or related tools like 'list_notebooks' for finding notebooks to export. The agent must infer usage from 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?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Get information' implies a read-only operation, it doesn't specify what type of information is returned (configuration, status, metrics), whether authentication is required, rate limits, or error conditions. The description is too vague about the actual behavior beyond the basic operation.
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 - a single sentence that directly states the tool's purpose. There's zero wasted language, and it's front-loaded with the essential information. Every word earns its place in this minimal description.
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 cluster operations in Databricks, no annotations, no output schema, and 0% schema description coverage, this description is insufficient. It doesn't explain what information is returned, how to interpret results, or provide context about cluster states. For a tool that presumably returns detailed cluster information, the description is too minimal.
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 and 1 parameter, the description doesn't add any meaning beyond what the input schema provides. It mentions 'a specific Databricks cluster' which implies the cluster_id parameter, but doesn't explain where to obtain this ID, its format, or validation requirements. The description doesn't 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get information') and resource ('about a specific Databricks cluster'), making the purpose evident. However, it doesn't distinguish this tool from its sibling 'list_clusters' which also provides cluster information but in a list format rather than for a specific cluster.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention that 'list_clusters' should be used to find cluster IDs first, or when to use this versus checking cluster status through other means. There's no explicit when/when-not usage 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 are provided, so the description carries the full burden of behavioral disclosure. While 'List' implies a read-only operation, the description doesn't specify whether this requires authentication, what format the results are returned in, whether there's pagination, rate limits, or any other behavioral characteristics. It's minimally adequate but lacks important operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single sentence that directly states the tool's purpose with zero wasted words. It's appropriately sized for a simple listing 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and 0% schema description coverage, the description is inadequate. It doesn't explain what the tool returns, how to interpret results, or provide any context about the DBFS environment. While the tool appears simple, the description leaves too many operational questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no information about the single parameter 'dbfs_path'. With 0% schema description coverage and no parameter information in the description, the agent has no semantic understanding of what this parameter does or how to use it effectively. The description doesn't 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('files and directories in DBFS'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from 'list_volume_files' which appears to be a sibling tool for listing files in a different location (volume vs DBFS).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of when to choose 'list_files' over 'list_volume_files' or other listing tools like 'list_clusters', 'list_jobs', etc. No prerequisites, exclusions, or context for usage is 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the action ('List') but lacks details on permissions, rate limits, pagination, output format, or error conditions. For a read operation without annotations, this leaves significant gaps in understanding how the tool behaves beyond its 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place by contributing essential information about the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% schema coverage, no output schema, and multiple sibling tools, the description is incomplete. It covers the basic purpose but misses critical context like parameter details, behavioral traits, output expectations, and differentiation from similar tools. For a list operation in a complex environment, this leaves too many unanswered questions.
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 implies a 'path' parameter contextually ('in a workspace directory') but doesn't explain what the path represents, its format, or valid values. This adds minimal semantic value beyond the bare schema, failing to adequately document the single required parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('notebooks'), and specifies the scope ('in a workspace directory'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'list_files' or 'list_volume_files', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance by mentioning 'in a workspace directory', but offers no explicit advice on when to use this tool versus alternatives like 'list_files' or 'list_volume_files'. There's no mention of prerequisites, exclusions, or comparative contexts, leaving usage decisions largely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it 'gets' status and results, implying a read-only operation, but doesn't disclose behavioral traits like authentication needs, rate limits, error handling, or what 'status' and 'results' entail (e.g., success/failure, data format). 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Get the status and results') and specifies the key parameter ('by statement_id'). There is zero waste, and 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and low schema coverage, the description is incomplete. It doesn't explain what 'status' and 'results' mean, how they're returned, or any dependencies (e.g., statement_id from execute_sql_nonblocking). For a tool that retrieves SQL execution outcomes, more context is needed to understand its full usage and behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning by specifying that statement_id is used to identify the SQL statement, which the input schema only titles as 'Statement Id' with 0% coverage. However, with only 1 parameter and low schema coverage, it partially compensates but doesn't explain what a statement_id is (e.g., from execute_sql_nonblocking) or its format. Baseline is 3 as it adds some semantics beyond the bare 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 verb ('Get') and resource ('status and results of a SQL statement'), specifying it's done 'by statement_id'. It distinguishes from siblings like execute_sql (which runs SQL) and list_jobs (which lists jobs), but doesn't explicitly contrast with similar tools like get_cluster or get_job. The purpose is specific but could be more differentiated from other 'get' tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a statement_id from execute_sql_nonblocking), when-not-to-use scenarios, or comparisons to siblings like list_job_runs for job status. Usage is implied only by the tool name and description, lacking explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'terminate' which implies a destructive mutation, but doesn't disclose critical behavioral traits: whether termination is irreversible, requires specific permissions, has side effects (e.g., data loss), or rate limits. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (destructive mutation), lack of annotations, no output schema, and 0% schema description coverage, the description is incomplete. It fails to address key aspects like behavioral risks, parameter details, or expected outcomes, making it insufficient for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds no parameter semantics beyond what the schema's title ('Cluster Id') implies. It doesn't explain what 'cluster_id' represents, its format, or where to find it. With only one parameter, the baseline is 4, but the lack of any parameter details in the description reduces it to 3.
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 ('terminate') and target resource ('a Databricks cluster'), providing specific verb+resource. However, it doesn't differentiate from sibling tools like 'start_cluster' or 'get_cluster' beyond the obvious action difference, missing explicit sibling 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/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 about prerequisites (e.g., cluster must be running), exclusions (e.g., cannot terminate if jobs are active), or comparisons to siblings like 'start_cluster' or 'list_clusters'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the default serverless behavior, which adds some context, but it doesn't disclose critical behavioral traits such as whether this is a mutating operation, what permissions are required, if there are rate limits, or what the output looks like. For a creation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that is front-loaded with the core purpose and includes an important behavioral detail (serverless default). There is no wasted text, 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.
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 job creation tool with 6 parameters, no annotations, and no output schema, the description is incomplete. It lacks details on parameter meanings, behavioral implications (e.g., mutation effects, error handling), and expected outputs, leaving significant gaps for an AI agent to understand and use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It only mentions 'serverless by default', which relates to the 'use_serverless' parameter, but it doesn't explain the semantics of other parameters like 'job_name', 'notebook_path', 'timeout_seconds', 'parameters', or 'cluster_id'. This fails to add sufficient meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a new Databricks job') and the resource ('to run a notebook'), which is specific and actionable. It distinguishes from siblings like 'run_job' by focusing on creation rather than execution, though it doesn't explicitly contrast with all siblings like 'create_cluster' or 'create_notebook'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating jobs to run notebooks, with a default behavior ('uses serverless by default'), but it doesn't provide explicit guidance on when to use this tool versus alternatives like 'run_job' or 'create_cluster'. It offers some context but lacks clear exclusions or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the blocking behavior, which is useful, but lacks critical details such as permissions required, potential side effects (e.g., data modification), error handling, or performance implications. For a tool that executes SQL statements, this is a significant gap in 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Execute a SQL statement') and adds essential behavioral detail ('wait for completion (blocking)'). There is no wasted verbiage, 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of executing SQL (potentially involving data mutation, permissions, and performance), no annotations, no output schema, and low parameter semantics, the description is incomplete. It lacks details on return values, error cases, and the broader context of SQL execution in this environment, making it insufficient for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'SQL statement' which relates to the 'statement' parameter, but doesn't explain the purpose of 'warehouse_id', 'catalog', or 'schema_name', nor does it provide any syntax or format guidance. With 4 parameters and no schema descriptions, this is inadequate.
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 ('Execute a SQL statement') and specifies the blocking behavior ('wait for completion'), which distinguishes it from the sibling 'execute_sql_nonblocking'. However, it doesn't specify the resource or context (e.g., database, warehouse) beyond what's implied by the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning 'blocking', which suggests this tool should be used when waiting for SQL execution completion is required, as opposed to the non-blocking sibling. However, it doesn't explicitly state when to use this versus alternatives like 'execute_sql_nonblocking' or other SQL-related tools, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the non-blocking behavior and immediate return of a statement_id, which is useful. However, it lacks critical behavioral details such as execution timeouts, error handling, authentication requirements, or how to retrieve results later (e.g., using 'get_sql_status'). For a tool with no annotations, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the key action and outcome. It wastes no words and efficiently communicates the core functionality. Every part of the sentence earns its place by specifying the action, behavior, and return 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 complexity of a SQL execution tool with no annotations, no output schema, and 4 parameters (2 required), the description is incomplete. It covers the high-level behavior but misses details on parameter usage, result retrieval (e.g., via 'get_sql_status'), error scenarios, and integration with sibling tools. For such a tool, more context is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It doesn't mention any parameters or their semantics (e.g., what 'warehouse_id' refers to, the format of 'statement', or the purpose of 'catalog' and 'schema_name'). With 4 parameters and no schema descriptions, the description adds no value beyond what the bare schema provides, failing to clarify usage.
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 ('Start SQL statement execution') and the resource (SQL statement), and specifies the non-blocking behavior with immediate return of a statement_id. It distinguishes from the sibling 'execute_sql' by highlighting the non-blocking aspect, though it doesn't explicitly name the sibling. The purpose is specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for asynchronous SQL execution where immediate results aren't needed, contrasting with the blocking 'execute_sql' sibling. However, it doesn't explicitly state when to use this tool versus alternatives like 'execute_sql' or provide context on prerequisites (e.g., warehouse availability). The guidance is implied but not detailed.
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 the action but doesn't describe what 'List all' entails—such as pagination behavior, return format, authentication requirements, or rate limits. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste—it directly states the tool's purpose without unnecessary 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what the listing returns (e.g., cluster IDs, names, statuses) or behavioral aspects like ordering or limits. For a tool with no structured data to supplement it, the description should provide more context to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, earning a baseline score of 4 for not introducing confusion or redundancy.
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 ('List') and resource ('Databricks clusters') with scope ('all'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_cluster' (which retrieves a specific cluster) or 'list_jobs' (which lists different resources), missing explicit sibling 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to use 'list_clusters' instead of 'get_cluster' (for specific cluster details) or other list tools like 'list_jobs', nor does it specify prerequisites or exclusions. This leaves usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Start') but doesn't mention permissions required, whether it's idempotent, rate limits, or what happens if the cluster isn't terminated. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any fluff. It's appropriately sized and front-loaded, making it easy to understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of starting a cluster (a mutation operation), no annotations, no output schema, and minimal parameter coverage, the description is inadequate. It should explain more about behavior, outcomes, or error conditions to be 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 description doesn't add any parameter details beyond the schema, but with only 1 parameter and 0% schema description coverage, the baseline is high. The tool name and description imply 'cluster_id' refers to a terminated cluster, which adds minimal context, keeping it near the baseline.
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 ('Start') and the resource ('a terminated Databricks cluster'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from siblings like 'create_cluster' or 'run_job', which might involve cluster operations, so it misses full sibling 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/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 'create_cluster' for new clusters or 'run_job' for job execution. It lacks any context about prerequisites, exclusions, or typical scenarios, leaving usage unclear.
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 of behavioral disclosure. It states the tool returns detailed file information (names, sizes, modification times) and mentions it's useful for managing large datasets, which adds context about output format and scale. However, it doesn't cover potential limitations like pagination, error conditions, or authentication requirements, leaving gaps for a read 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for Args, Returns, Example, and Note, making it easy to scan. It's appropriately sized with no redundant sentences, though the Note slightly overlaps with Returns. Every sentence adds value, such as clarifying the JSON output format and dataset management context.
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 low complexity (1 parameter, no annotations, no output schema), the description is reasonably complete. It covers purpose, parameter semantics, return format, and an example. However, it lacks details on error handling or performance considerations, which could be useful for a file-listing tool in large datasets.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully compensate. It clearly explains the single parameter 'volume_path' with a definition, example format, and usage in the example code. This adds essential meaning beyond the bare schema, making the parameter's purpose and format understandable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('List files and directories') and resource ('in a Unity Catalog volume'), distinguishing it from siblings like 'list_files' (likely for different storage) and 'upload_file_to_volume' (a write operation). The verb+resource combination is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing volume contents but provides no explicit guidance on when to use this tool versus alternatives like 'list_files' (which might list different storage locations) or 'upload_file_to_volume' (for writing). The example shows a typical use case but lacks comparative 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.
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 and does well by disclosing key behavioral traits: it mentions pagination mechanics, token limit considerations ('keeps response under token limits'), performance trade-offs ('set false for faster response'), and case-insensitive filtering. It also details the return structure, including pagination info and job data with latest run details. However, it lacks information on rate limits, authentication requirements, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and well-structured: it starts with a clear purpose statement, then details arguments with explanations, and concludes with return value information. Every sentence adds value—no fluff or repetition. The use of sections (Args, Returns) enhances readability without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, no annotations, no output schema), the description is largely complete: it covers purpose, parameters, return format, and pagination behavior. However, it lacks context on authentication, error cases, or rate limits, which are important for a listing tool in a cloud service like Databricks. The absence of an output schema is mitigated by the detailed return description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate fully, which it does excellently. It adds meaningful semantics for all 4 parameters: explains 'limit' default and token limit rationale, describes 'offset' usage with pagination guidance, specifies 'created_by' format and case-insensitivity, and clarifies 'include_run_status' impact on performance. This goes well beyond the basic schema to provide practical usage context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List Databricks jobs with pagination and filtering.' It specifies the verb ('List') and resource ('Databricks jobs'), and distinguishes it from siblings like 'list_job_runs' by focusing on jobs rather than runs. However, it doesn't explicitly contrast with other listing tools like 'list_clusters' or 'list_notebooks' beyond the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing jobs with optional filtering and pagination, but doesn't explicitly state when to use this tool versus alternatives. For example, it doesn't clarify if this should be used over 'list_job_runs' for job metadata or when filtering by creator is needed. The guidance is limited to functional parameters rather than contextual decision-making.
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 key behavioral traits: it's a read operation (implied by 'List'), returns detailed status/duration info, and specifies ordering (most recent first). However, it doesn't mention pagination, rate limits, authentication requirements, or error conditions that would be helpful for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose statement followed by organized sections for Args and Returns. Every sentence earns its place by providing essential information without redundancy. The formatting with clear section headers makes it easy 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?
For a tool with 2 parameters, no annotations, and no output schema, the description does well by explaining parameters, return format, and behavior. However, it could be more complete by mentioning potential error cases, authentication requirements, or rate limits given the absence of annotations. The return format description partially compensates for the lack of output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant value beyond the input schema, which has 0% description coverage. It explains that job_id is optional and what happens when omitted ('omit to see runs across all jobs'), clarifies the limit default value and ordering ('most recent first'), and provides context not present in the schema's bare property definitions.
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 ('List') and resource ('recent job runs') with specific scope ('with detailed status and duration information'). It distinguishes from siblings like 'list_jobs' by focusing on runs rather than job definitions, and from 'get_sql_status' by covering job execution status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use it (to see runs across all jobs or for a specific job) and includes parameter guidance (optional job_id, default limit). However, it doesn't explicitly state when NOT to use it or name specific alternatives among siblings for different scenarios.
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 full burden and does well by disclosing key behavioral traits: it mentions chunked upload with retry logic for large files (>10MB), default overwrite behavior, and the JSON return structure. However, it doesn't cover potential error conditions, authentication requirements, or rate limits that would be valuable for an upload operation.
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 well-structured with clear sections (Args, Returns, Example, Note), front-loads the core purpose, and every sentence adds value. The example is practical and illustrative without being verbose. No wasted words or redundant information.
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 file upload tool with no annotations and no output schema, the description does an excellent job covering parameters, return format, and behavioral notes. However, it could benefit from mentioning error handling, permission requirements, or file size limits beyond the 10MB threshold mentioned. The absence of an output schema makes the return format description particularly valuable.
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?
With 0% schema description coverage, the description fully compensates by providing clear explanations for all 3 parameters: it defines each parameter's purpose, provides concrete examples of expected values, and explains the default behavior for 'overwrite'. This adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Upload a local file') and target resource ('to Databricks File System (DBFS)'), distinguishing it from sibling tools like 'upload_file_to_volume'. It uses precise language that leaves no ambiguity about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool ('DBFS is good for temporary files, scripts, and smaller datasets') and mentions large file handling, but doesn't explicitly contrast when to use this versus the sibling 'upload_file_to_volume' tool. It offers practical guidance but lacks explicit alternative comparisons.
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 full burden and does well by disclosing key behavioral traits: handles large files (multi-GB), includes progress tracking, provides proper error handling, and describes the return format (JSON with success status, file size, upload time). It doesn't mention authentication requirements or rate limits, but covers most operational aspects.
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 well-structured with clear sections (Args, Returns, Example, Note), front-loads the core purpose, and every sentence adds value. It's appropriately sized for a 3-parameter tool with no annotations, avoiding both verbosity and under-specification.
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 complexity of a file upload operation with no annotations and no output schema, the description provides complete context: clear purpose, detailed parameter semantics, return format description, example usage, and behavioral notes about large file handling. It leaves no significant gaps for agent understanding.
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?
With 0% schema description coverage, the description fully compensates by providing detailed parameter explanations in the Args section, including examples for both path parameters and default value for overwrite. It adds substantial meaning beyond the bare schema, making all three parameters completely understandable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Upload a local file') and target resource ('to a Databricks Unity Catalog volume'), distinguishing it from sibling tools like 'upload_file_to_dbfs'. It provides a complete verb+resource+scope statement that leaves no ambiguity about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides usage guidance with 'Perfect for uploading extracted datasets to Unity Catalog volumes for processing' and distinguishes it from alternatives by specifying the target (Unity Catalog volumes vs. DBFS). The example and note further clarify appropriate use cases, including handling large files with progress tracking.
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:

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

Score Badge

Copy to your README.md:

[![databricks-mcp-server MCP server](https://glama.ai/mcp/servers/samhavens/databricks-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/samhavens/databricks-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/samhavens/databricks-mcp-server'

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